Skip to content
This repository has been archived by the owner on Apr 22, 2024. It is now read-only.

fix: General Fixes #7

Merged
merged 25 commits into from
Feb 20, 2024
Merged

fix: General Fixes #7

merged 25 commits into from
Feb 20, 2024

Conversation

JasonN3
Copy link
Collaborator

@JasonN3 JasonN3 commented Feb 16, 2024

  • Add a VSCode Dev Container for easier development
  • Create standard for workflow names.
    build-*
    test-*
  • Rename Dockerfile to Containerfile to match other repos
  • Update build workflow to use Containerfile instead of Dockerfile
  • Generate multiple images. One for each version 38, 39, and 40 (n +/- 1)
  • Move build workflow to action.yml
  • Update .gitignore for new resulting ISO path
  • Add .github/CODEOWNERS
  • Standardize Makefile variable format
  • Update README.md with information
  • Rename resulting ISO to @IMAGE_NAME@-@IMAGE_TAG@ to match container that gets deployed

@JasonN3 JasonN3 self-assigned this Feb 16, 2024
@JasonN3 JasonN3 marked this pull request as draft February 17, 2024 01:25
@JasonN3 JasonN3 marked this pull request as ready for review February 19, 2024 14:39
@JasonN3 JasonN3 requested a review from noelmiller February 19, 2024 14:39
Makefile Show resolved Hide resolved
Makefile Show resolved Hide resolved
README.md Show resolved Hide resolved
Makefile Outdated Show resolved Hide resolved
action.yml Show resolved Hide resolved
@noelmiller
Copy link
Member

@castrojo @bsherman @KyleGospo @EyeCantCU
Since this is a larger change that uses https://github.com/ublue-os/build-action as a key building block, I need more folks than just me to weigh in on this PR.

@JasonN3 to clarify for everyone, build-action would ultimately be replacing individual build.yml files with one unified action?

If the above is true, I would like to discuss the advantages and disadvantages of the approach of using one unified build action with a matrix for all separate repos, vs each repo having their own build.yml actions defined.

@JasonN3
Copy link
Collaborator Author

JasonN3 commented Feb 20, 2024

Yes, the intended purpose of build-action is to unify all of the build processes. Right now the same workflow is copied to multiple repos and then modified and some variables are used in the same way but with different names. Some workflows also have features that other workflows don't but could have. The end goal for that repo is to replace all of that with a call to a central action that will surface the same capabilities to all of the repos. That repo started off based off the workflow in bazzite and then was tested against main and bluefin as well as this repo. This is the first repo actually using it though. Adding it into the other repos would be a gradual process that would be done one repo at a time to ensure the builds do not break or change.

@JasonN3
Copy link
Collaborator Author

JasonN3 commented Feb 20, 2024

To clarify something else, the build-action repo workflow won't build the container images. It is just an action to be called by the rest of the repos, just like isogenerator. Each repo will still have a matrix to define the parameters for building.

.github/workflows/build-container.yml Outdated Show resolved Hide resolved
.github/workflows/build-container.yml Outdated Show resolved Hide resolved
Copy link
Member

@EyeCantCU EyeCantCU left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Dropped a few comments otherwise this looks great

action.yml Show resolved Hide resolved
.github/CODEOWNERS Outdated Show resolved Hide resolved
.github/workflows/test-iso.yml Show resolved Hide resolved
Makefile Outdated Show resolved Hide resolved
@bsherman
Copy link

To clarify something else, the build-action repo workflow won't build the container images. It is just an action to be called by the rest of the repos, just like isogenerator. Each repo will still have a matrix to define the parameters for building.

I think I see how things are interrelated here, but I'll state my understanding for confirmation.

As of this PR, isogenerator repo has:
the primary product:

  • an action to be consumed by workflows (ublue image repos) which will generate an iso from said container images

self-testing:

  • workflow build-container-image uses build-image action (from the repo of the same name) for building an isogenerator:VERSION OCI image, published to ghcr (actually contains some ublue image)
  • workflow test-iso which uses both the above isogenerator action and the above generated isogenerator:VERSION OCI image to generate ISO images for testing.

While blue-image action is consumed here, implementing it in other repos is not a direct requirement for this PR, and as you said, @JasonN3 , we can handle that over time. I think that process is a distinct question from the implementation of this isogenerator PR, so we can discuss the details on that effort as appropriate.

Is this a fair summary of the PR?

@JasonN3
Copy link
Collaborator Author

JasonN3 commented Feb 20, 2024

To clarify something else, the build-action repo workflow won't build the container images. It is just an action to be called by the rest of the repos, just like isogenerator. Each repo will still have a matrix to define the parameters for building.

I think I see how things are interrelated here, but I'll state my understanding for confirmation.

As of this PR, isogenerator repo has: the primary product:

* an action to be consumed by workflows (ublue image repos) which will generate an iso from said container images

self-testing:

* workflow `build-container-image` uses `build-image` action (from the repo of the same name) for building an `isogenerator:VERSION` OCI image, published to ghcr (actually contains some ublue image)

* workflow `test-iso` which uses both the above `isogenerator` action and the above generated `isogenerator:VERSION` OCI image to generate ISO images for testing.

While blue-image action is consumed here, implementing it in other repos is not a direct requirement for this PR, and as you said, @JasonN3 , we can handle that over time. I think that process is a distinct question from the implementation of this isogenerator PR, so we can discuss the details on that effort as appropriate.

Is this a fair summary of the PR?

Close.
You're right onbuild-container-image.
test-iso does not use the container image. It just uses the action (action.yml) from this repo.

build-container-image:
Calls the action build-action to create an OCI image for this repo using Containerfile and push to ghcr.io/ublue-os/isogenerator:$INSTALLER_VERSION. INSTALLER_VERSION can be different than the version of what gets installed. It just indicates which version of Fedora the installer will be built from.

test-iso:
Calls the action isogenerator to create an ISO for ghrci.io/ublue-os/base-main:$VERSION. The resulting ISO gets attached to the workflow run, but isn't used for anything other than potentially verifying that it was built correctly.

The container image is just being built for development work. I don't really care for it since everything is already in the Makefile, but it was wanted, so I left it in there. However, calling it as the workflow makes it harder to debug and has the potential to result in the wrong version being run, so I kept the individual make commands for the workflow.

Copy link

@bsherman bsherman left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for all the effort and answering my questions!

@JasonN3 JasonN3 added this pull request to the merge queue Feb 20, 2024
Merged via the queue into main with commit a8cdedd Feb 20, 2024
8 checks passed
@JasonN3 JasonN3 deleted the jasonn3-fixes branch February 20, 2024 22:37
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants